¿Qué es un sistema de protección de datos? ¿Cómo se hace la protección de datos? ¿Qué es privacidad y protección de datos?

Un dato es una representación simbólica, atributo o característica de una entidad que no tiene valor semántico (sentido) en sí mismo. Luego de atravesar un procesamiento se convierte en información: el dato es tratado y es útil para realizar una tarea (cálculos, informes, toma de decisiones, etc.), soportando el negocio y/o actividad de la organización. Por ello, es fundamental proteger esa información cumpliendo con los requerimientos de seguridad para satisfacer las necesidades del negocio. Estos requerimientos son:

• Confidencialidad: se refiere a la protección de información sensitiva contra revelación no autorizada. Es decir, que sólo accedan a la información aquellos usuarios autorizados.
• Integridad: está relacionada con la precisión y completitud de la información, así como con su validez de acuerdo a los valores y expectativas del negocio. Para ello es fundamental que la información sólo pueda ser creada y modificada por los usuarios autorizados.
• Disponibilidad: se refiere a que la información esté disponible cuando sea requerida por los procesos del negocio en cualquier momento (en tiempo y forma).

Con relación al acceso a los datos, existen muchos niveles de seguridad:

• Base de datos: software en ejecución, que es el SGBD.
• Sistema operativo: software sobre el que se ejecuta el SGBD.
• Aplicación: aplicaciones que interactúan de forma bidireccional con los datos del SGBD.
• Servidor: máquina física donde se aloja la base de datos.
• Red: vía por la que viajan los datos hasta la computadora del usuario y desde la misma hacia la base.
• Físico: acceso al lugar físico donde se encuentran los servidores, a la red o a la computadora que realiza la consulta a la base de datos.
• Humano: es el punto más débil y atacado a través de diversas técnicas para obtener el acceso a los datos.

Por más que se maneje muy bien la seguridad sobre la base de datos, si los restantes niveles de seguridad son desatendidos igualmente la base de datos será muy vulnerable.

Desde el SGBD se pueden establecer diferentes medidas de seguridad en varios niveles, algunas de las cuales ya son conocidas:

• Restricciones:
• Dominio.
• Tipo de dato.
• Integridad referencial.
• Otras, establecidas mediante triggers.
• Recuperación ante fallos: back up.
• Control de concurrencia.
• Autorizaciones.
• Vistas/stored procedures.
• Cifrado.

Autorización

Se pueden asignar a los usuarios varios tipos de autorización para diferentes partes de la base de datos. Cada uno de estos tipos de autorización se denomina privilegio. Se puede conceder a cada usuario todos estos tipos de privilegios, ninguno de ellos o una combinación de los mismos sobre partes concretas de la base de datos, como puede ser una relación o una vista.

En el SGBD se pueden gestionar las conexiones (log in), pudiendo crear usuarios autorizados e indicar cómo se autentican, desde dónde se puede conectar y otras limitaciones. Se puede permitir al usuario al que se le ha concedido alguna forma de autorización que transmita (conceda) esa autorización a otros usuarios o que retire (revoque) una autorización concedida previamente.

El lenguaje de definición de datos de SQL incluye comandos para conceder y retirar privilegios. Con el nombre de lenguaje de control de datos (DCL) se hace referencia a la parte del lenguaje SQL que se ocupa de los apartados de seguridad y de la integridad en el procesamiento concurrente.

La instrucción GRANT se utiliza para conceder autorizaciones. La forma básica de esta instrucción es:

GRANT ON TO

Pueden concederse privilegios globales sobre toda la base de datos o privilegios específicos sobre una tabla en particular.

La lista de privilegios permite la concesión de varios privilegios con un solo comando.

Privilegio

Descripción

Privilegios para el acceso a datos

SELECT

Autorización de lectura. Autoriza al usuario a leer los datos.

INSERT

Autorización de inserción. Puede especificar una lista de atributos; cualquier inserción en la relación debe especificar sólo esos atributos y el sistema asigna al resto de los atributos valores predeterminados (si hay alguno definido para ellos) o los define como nulos.

UPDATE

Autorización de actualización. Al igual que la anterior, puede concederse sobre todos los atributos de la relación o sólo sobre algunos. Si se omite la lista de atributos, el privilegio UPDATE se concede sobre todos los atributos de la relación.

DELETE

Autorización de borrado.

Privilegios para modificar el esquema (diccionario de datos)

CREATE

Autorización para crear nuevas tablas o atributos

ALTER

Autorización para añadir atributos a las tablas o para eliminarlos.

DROP

Autorización para eliminar tablas.

REFERENCES

Permite que los usuarios declaren claves externas al crear las relaciones. Las restricciones de clave externa restringen las operaciones de borrado y de actualización de la relación a la que se hace referencia. Se concede sobre atributos concretos de manera parecida a la del privilegio UPDATE.

EXECUTE

Autoriza a los usuarios a ejecutar funciones o procedimientos. Por tanto, sólo los usuarios que tienen este privilegio sobre una función pueden llamarla.

USAGE

Autoriza a los usuarios a usar el dominio especificado. Los dominios se corresponden con el concepto de tipo de los lenguajes informáticos y pueden ser definidos por los usuarios.

INDEX

Creación y eliminación de índices.

Los PRIVILEGES pueden utilizarse como forma abreviada de todos los privilegios que se pueden conceder. El usuario que crea una relación nueva recibe de manera automática todos los privilegios sobre esa relación.

El nombre de usuario PUBLIC hace referencia a todos los usuarios actuales y futuros del sistema. Por tanto, los privilegios concedidos a PUBLIC se conceden de manera implícita a todos los usuarios actuales y futuros.

De manera predeterminada, los usuarios o roles a los que se les conceden privilegios no están autorizados a concederlos a otros usuarios o roles. Si se desea conceder un privilegio y permitir que el receptor se lo conceda a otros usuarios, hay que añadir la cláusula WITH GRANT OPTION a la instrucción GRANT correspondiente.

El creador de un objeto (relación/vista/rol) tiene todos los privilegios sobre ese objeto, incluido el privilegio de conceder privilegios a otros.

La autorización no solamente es para los usuarios sino también para las aplicaciones que consultan la base de datos. Al momento de conceder el acceso, el SGBD no reconoce la diferencia entre usuario y aplicación: para este son lo mismo.

Roles

El concepto de roles permite asignar un conjunto específico de privilegios a usuarios que cumplan funciones similares. En la base de datos se crea un conjunto de roles y las autorizaciones se pueden conceder a los roles exactamente igual que se conceden a los usuarios. Se concede un conjunto de roles (que puede estar vacío) que está autorizado a desempeñar a cada usuario de la base de datos.

Cualquier autorización que se pueda conceder a los usuarios se puede conceder a los roles. Los roles se conceden a los usuarios igual que las autorizaciones. Y, como otras autorizaciones, también se les puede conceder a los usuarios autorización para conceder un rol concreto a otros.

La sintaxis para crear roles en SQL es:

CREATE ROLE nombre rol

En definitiva, los privilegios de los usuarios o roles consisten en:

• Todos los privilegios concedidos directamente al usuario o rol.
• Todos los privilegios concedidos a los roles que se han concedido al usuario o rol.

También puede haber cadenas de roles, es decir, roles específicos que hereden privilegios de otros roles más generales. De esa forma, al asignar un rol específico a un usuario éste indirectamente poseerá también los privilegios concedidos a los roles más generales.

Retirada de privilegios

Para retirar una autorización se emplea la instrucción REVOKE. Su forma es casi idéntica a la de GRANT:

REVOKE ON FROM

El usuario al que se le ha concedido alguna forma de autorización puede estar autorizado a transmitir esa autorización a otros usuarios. Sin embargo, hay que tener cuidado con el modo en que se puede transmitir esa autorización entre los usuarios para asegurar que la misma pueda retirarse en el futuro. En estos casos la retirada de privilegios resulta más complicada.

Cuando la retirada de privilegios de un usuario o rol provoca que otros usuarios o roles también pierdan esos privilegios ocurre lo que se llama retirada en cascada. Éste es el comportamiento predeterminado. Puede restringirse utilizando la cláusula RESTRICT: en ese caso, el sistema devuelve error si se produce una retirada en cascada y no lleva a cabo la acción de retirada.

La retirada en cascada es inapropiada en muchas situaciones. Por ello, SQL permite que los roles, en vez de los usuarios, concedan privilegios: si un rol otorga un privilegio, en caso de que el usuario concedente pierda esos privilegios, el usuario a quien los concede no los pierde ya que para el sistema el concedente fue un rol y no un usuario.

Privilegios sobre vistas, funciones y procedimientos

Cuando un usuario formula una consulta para acceder al resultado de una vista, el procesador de consultas traduce la vista en una consulta a las relaciones reales de la base de datos. Por lo tanto, el sistema debe comprobar la autorización de dicho usuario sobre esas relaciones. El usuario que crea una vista no recibe necesariamente todos los privilegios sobre esa vista. Sólo recibe los privilegios que no le dan ninguna autorización adicional respecto de las que ya tenía. Si un usuario crea una vista sobre la que no se le puede conceder ninguna autorización, el sistema denegará la solicitud de creación de esa vista.

Dado que por el momento no hay un esquema que otorgue permisos sobre un conjunto específico de filas, hoy en día se pueden utilizar las vistas para otorgar permisos a un usuario sobre un subconjunto de filas. Si el resultado de la consulta se va a utilizar en otras tiene sentido que se use una vista; para trabajarlo de otra manera tal vez sea mejor un stored procedure.

El privilegio EXECUTE se puede conceder sobre una función o sobre un procedimiento y permite que el usuario los ejecute. De manera predeterminada, al igual que con las vistas, las funciones y los privilegios tienen todos los privilegios que tenía su creador. En efecto, la función o el procedimiento se ejecutan como si los invocara el usuario que los creó. El usuario actual de la sesión se configura como creador de la función o del procedimiento mientras se ejecutan.

A una aplicación se le pueden dar permisos para consultar toda una tabla o de propietario de la base de datos (que es lo más común). Sin embargo, un esquema más seguro es crear stored procedures que digan exactamente lo que tiene que hacer la aplicación y que ésta sólo llame a los stored procedures utilizando variables (es decir, la aplicación realiza la acción sobre la base de datos a través de stored procedures). Si alguien captura las credenciales de la aplicación, está más limitado en su accionar si el esquema de seguridad es este que si la aplicación tiene permisos directos sobre la tabla (el daño es menor).

Seguridad

Cifrado

El cifrado es una técnica que protege o autentica a un dato, mensaje o usuario al aplicar un algoritmo criptográfico. Es mejor práctica conocer una clave específica para cifrar/descifrar el dato. La idea es hacer el mensaje entendible para quien no deba leerlo y verificar que quien dice haberlo escrito efectivamente lo haya hecho. De todos modos, debería existir una forma en la que quien deba leerlo pueda hacerlo.

Una buena técnica de cifrado posee las propiedades siguientes:

• Resulta relativamente sencillo para los usuarios autorizados cifrar y descifrar los datos.
• No depende de lo poco conocido que sea el algoritmo sino de un parámetro del algoritmo denominado clave de cifrado.
• Es extremadamente difícil para un intruso determinar la clave de cifrado.

El cifrado puede ser:

• Sin clave: método en el que basta con conocer el algoritmo para encriptar y desencriptar el mensaje. El problema de este método es la posibilidad de reutilizar el algoritmo: cualquiera que lo conozca está en condiciones de cifrar y descifrar los mensajes.
• Con clave: a la necesidad de saber con qué algoritmo se encriptó el mensaje se añade una clave a través de la cual se realizó el cifrado. Existen dos tipos:
• Simétrico: emisor y receptor utilizan la misma clave para encriptar y desencriptar el mensaje, respectivamente. El problema de este método es que cualquiera que posea la clave podrá enviar mensajes encriptados con la misma y leer mensajes que también se hayan codificado con esa clave. Además, si sólo el emisor conoce la clave, el receptor no podrá leer el mensaje y el emisor tampoco podrá recibir mensajes encriptados con la clave en cuestión. Por otro lado, existe el riesgo de que la clave sea interceptada por terceros cuando el emisor se la envía al receptor. Eso implica, también, que el emisor no tiene la seguridad de estar comunicándose con quien cree hacerlo.
• Asimétrico: se utilizan dos claves, en donde una descifra lo que cifra la otra y viceversa.

Cifrado asimétrico de clave pública y privada

El usuario posee dos claves: una pública y la otra privada. Todas las claves públicas están publicadas: cualquiera puede verlas. Cada clave privada sólo la conoce el usuario al que pertenece. Entonces, el emisor cifra el mensaje con su clave privada y el receptor descifra el mensaje con la clave pública del usuario, lo cual garantiza la autenticidad de quien envía (en la medida que el emisor haya mantenido privada su clave).

Al momento de responder el mensaje, el receptor cifra su respuesta con la clave pública del usuario y éste lo descifra con su clave privada. De esa forma, el receptor se aseguró de que su respuesta sólo la podría leer el destinatario. Este esquema de cifrado también garantiza que el mensaje no fue alterado: si se cambia un carácter del mensaje encriptado se va a decodificar como otro mensaje que no tendrá sentido.

Implementado este mecanismo, puede utilizarse para transmitir claves simétricas.

Para que el usuario pueda estar seguro de que está interactuando con el destinatario auténtico debe tener la clave pública del mismo. Esto plantea el problema de hacer que el usuario consiga la clave pública. La autenticación se puede conseguir mediante un sistema de certificados digitales, en el que las claves públicas están firmadas por una agencia de certificación, cuya clave pública es bien conocida.

Los certificados digitales se usan mucho para autentificar los sitios Web ante los usuarios, para evitar que sitios malévolos suplantan a otros sitios Web. En el protocolo HTTPS (la versión segura del protocolo HTTP) el sitio proporciona su certificado digital al navegador, que lo muestra entonces al usuario. Si el usuario acepta el certificado, el navegador usa la clave pública proporcionada para cifrar los datos. Los sitios malévolos pueden tener acceso al certificado, pero no a la clave privada y, por tanto, no podrá descifrar los datos enviados por el navegador. Sólo el sitio auténtico, que tiene la clave privada correspondiente, puede descifrar los datos enviados por el navegador.

Los certificados digitales también se pueden usar para autenticar a los usuarios. El usuario debe remitir al sitio un certificado digital que contenga su clave pública; el sitio comprueba que el certificado haya sido firmado por una autoridad de confianza.

Hash

Un hash permite cifrar un mensaje de forma tal que no se pueda descifrar con ningún algoritmo. Es decir, no se puede recuperar el mensaje ni siquiera teniendo el hash. Funciona de forma tal que dos mensajes diferentes no llevan al mismo hash: sólo lo hace el mensaje original que fue cifrado con esa técnica.

Uno de los usos del hash es para validar una contraseña de acceso: en vez de almacenar contraseñas, se les aplica un hash y se almacena el texto encriptado. Cuando un usuario intenta iniciar sesión, se compara el hash guardado con el hash obtenido de la contraseña ingresada. Dado que dos mensajes iguales generan el mismo hash, la contraseña será válida. Por otro lado, al guardarse los hashes y no las contraseñas, ante un eventual ataque éstas no quedan expuestas. No obstante, este mecanismo es vulnerable a los ataques de diccionarios de contraseñas (se aplican hash a las contraseñas más comunes para poder conocerlas).

Frente a estos ataques es posible protegerse usando un salto, que consiste en un añadido de caracteres aleatorio (por ej.: concatenar la contraseña al ID del usuario). De esta forma, aunque dos usuarios usen la misma clave, los hashes resultantes serán diferentes.

Firma digital

Dado que el hash permite comparar texto de forma segura, se lo utiliza para implementar la firma digital. Lo que se hace es aplicar el hash al mensaje y al resultado cifrar con la clave privada. Al descifrarlo con la clave pública y aplicar el hash al mensaje, si ambos son iguales significa que tanto el emisor como el mensaje son auténticos (por supuesto que para que esto sea posible, se envía el mensaje sin cifrar también, se usa para documentos que no importa que se sepa su contenido). La firma va enganchada al mensaje.

Las firmas digitales también sirven para garantizar el no repudio. Es decir, en el caso de que la persona que creó los datos afirmará posteriormente que no los creó (el equivalente electrónico de afirmar que no se ha firmado un talón) se puede probar que esa persona tiene que haber creado los datos (a menos que su clave privada haya caído en manos de otros).

Cifrado en DBMS

El cifrado puede utilizarse para encriptar los datos de una base de datos. Normalmente se usa el cifrado simétrico, salvo que los datos de la misma deban enviarse a algún otro sitio. Existen funciones de cifrado con claves embebidas en el DBMS.

En el contexto de las bases de datos, el cifrado se puede llevar a cabo en diferentes niveles.

• En el nivel inferior, los bloques de disco que contienen datos de la base de datos se pueden cifrar, usando una clave disponible para el software del sistema de bases de datos.
• En los sistemas de bases de datos compartidos se aplica el cifrado antes de que los datos lleguen a la base de datos.